by Michael Marchuk
Software composed of distributed objects is one of the newest genres of application development. Software developers are making use of the ability to add application "components" as they need them through distributed object development models. This chapter exposes you to the basics behind the distributed object models and their uses in Internet application development.
Distributed object software development makes use of technologies like Java, JavaScript, ActiveX, and VBScript, which have all been recently introduced as key Internet components. Both Netscape and Microsoft have committed to the distributed object direction by including these technologies into their Internet browsers.
In this chapter you learn:
Application objects have been used for a long time. These objects may take the form of reusable code segments, subroutines, DLL code segments, and OLE controls. The more common view from a Windows perspective is that of the Object Linking and Embedding (OLE) controls. An OLE control is a self-contained application that provides specific functionality when called by another application.
OLE controls allow various properties and methods by which the data is stored and used between the main application and the OLE control. This type of functionality enables developers to reuse the OLE controls in other applications easily. Some examples of OLE controls include the multimedia control interface (MCI32.OCX) used to manage the interface between an application and a CD-ROM drive or an AVI movie file and the grid control (GRID32.OCX) which is used to handle the spreadsheet-like interface managing cells and their contents.
If you have used Visual Basic or VBA to write applications, you may be very familiar with OLE controls. These control objects provide the functionality from which the application can extend their own usefulness without recreating application code (see fig. 9.1). Since the functionality exists within the OLE control, the developer simply needs to call the functions within the control with the proper parameters to make use of the embedded functions.
Applications written to use OLE control objects can make use of the object's functionality easily.
The benefits of using controls become apparent when the focus of the development effort is directed away from the controls themselves and onto the functionality that the controls provide. Not only will the developer save time and effort from avoiding the duplication of rewriting control code, but the developer can significantly increase the functionality of the application by making use of properties which may not be essential to the operation of the application but are available through the control object they are calling. For example, a developer may not necessarily build a subroutine to handle interpreting all of the tags in an HTML 3.0 document when the only tag that needs to be used is the title. But if a control object can fit into the application to provide complete HTML decoding, the developer may be inclined to use the other features simply because there is no additional coding required.
Control objects are becoming an easy way to develop complex applications in a relatively short amount of time, because the objects provide the framework around which your application can be written. The popularity of control objects is evident with the increase in usage of programming environments like Visual Basic that use control objects to a great extent. The Internet extends this type of object usage through VBScript and JavaScript which utilize standard control objects as well as custom controls to create distributed applications.
Control objects supplied on diskette with applications make use of the traditional transportation mechanism for distributing programs. However, the Internet is challenging that method by introducing on-demand object distribution and application loading. Web pages sprinkled with scripts add functionality to the static content of an HTML page. The added functionality helps to distribute application logic to the end-user and ease the processing burden on the server.
But on-demand control object distribution has its own set of issues. For example, when an object is requested from a distributed application, the application must know where to get the object if it does not exist on the user's workstation. Additionally, because distributed objects are likely to be upgraded or modified periodically, applications which use these objects will need to be able to request the correct version of an object in order to ensure that the proper functionality is present for the program to operate.
This section briefly explains a few distributed object models and how they work. The next section, "Securing Distributed Objects," covers some of the details associated with guaranteeing that a particular object has not been infected with a virus or that the object comes from an unknown source.
The Component Object Model (COM) specification was initiated by Microsoft to cover the Object Linking and Embedding programming interface which stresses an open usage of software objects. The object components are distributed and called by an application to perform a particular function.
Vendors who supply COM-compliant application objects enable applications that are COM-compliant to make use of the functions within the object. The COM specification permits a handshaking between the application and the objects, which enables the application to make use of the most functionality available in the particular version of the object. The COM specification also requires location transparency for the execution of the object. In other words, an object may be running on the local workstation, or on a server across the Intranet. The application only needs to know how to access the features that the object is presenting and the object only needs to present its functions for the applications to use. The underlying functions within the object may be accomplished in any fashion, as long as they are consistent with this services the object is providing.
The Distributed Component Object Model (DCOM) was recently introduced by Microsoft to the Internet Engineering Task Force which manages Internet standards. The DCOM proposed standard establishes a uniform mechanism for building application-level protocols between servers and clients in a distributed environment.
The Distributed Component Object Model Request for Comment Internet standards draft is available at http://ds1.internic.net/internet-drafts/draft-brown-dcom-v1-spec-00.txt.
The Common Object Request Broker Architecture (CORBA) is an industry standard distributed object model that is maintained by the Object Management Group (OMG). The OMG established CORBA as a standard in 1991 to enable client applications to find the proper server objects for a particular request.
An ORB (Object Request Broker)is the middleware that establishes the client-server connections between distributed objects. Using an ORB, a client application can use a function on a server object, which can be local or over a network. The ORB manages the request and finds an object that can fulfill the request (see fig. 9.2). The client application does not have to know where the object is located, what programming language it uses, which operating system it is running on, or anything else which is not part of an object's application programming interface. This enables the ORB to provide cohesion between applications on different machines in distributed environments.
The ORB facilitates the process of fulfilling an application's object request.
The recent popularity of Java and JavaScript has brought the theory of distributed applications to a new generation of programmers. The basic concept behind the Java operating environment is the compiled "byte-code" which is executed on a remote client within a virtual machine environment. The remote client does not need to have any permanent storage facilities, because the application is downloaded from the server each time it is run. For example, if you want to display fancy marquee-style moving lights around a picture on an HTML page, you could embed the Java application which manages the marquee lights when the page is loaded.
This model of getting the code for the application every time it is run allows the code to remain up-to-date and does not require the client to manage any storage space to hold the marquee light application. In addition, the client running a Java application may not be a workstation or PC, but could be an appliance such as a telephone, because the application is running within the standard Java virtual machine environment within the real system environment of the hardware. The virtual machine concept is discussed later in this chapter in the section titled, "Virtual Machines."
Java applications can be very large depending on their complexity. Additionally, a large application requires a fast network or a lot of patience on a slow network connection. Because the application must be downloaded each time before it runs, a slow modem connection may cause large delays when using Java applications.
JavaScript, on the other hand, is a scripting language that requires the client workstation to have the base JavaScript classes from which the applications may use the various functions. For example, a JavaScript application may make use of an equation that calculates a mortgage payment schedule. The JavaScript application would use the math functions that are part of the JavaScript base classes that exist on the client workstation's hard drive.
JavaScript applications are relatively small and read much like Visual Basic source code. Because the application is really a script that draws from the functions already available on the client workstation, the download times and sizes are much smaller than Java applications.
To summarize the advantages of Java and JavaScript:
ActiveX is a recent technology offering by Microsoft that extends the OLE control concept a step further into the Internet realm. The ActiveX architecture is designed around the concept that the applications that are downloaded should be installed on the client workstation so that they may be used at a later time without requiring the application to be downloaded again. This mechanism saves download time and increases the application's speed because the object that is downloaded is a natively-compiled application.
VBScript is a subset of Visual Basic for Applications which allows ActiveX controls to be called like the OLE controls (OCX) are called from within Visual Basic. This type of mechanism opens up the ability to create interactive web pages to millions of Visual Basic programmers and Microsoft Office users who have created Visual Basic applications. The VBScript source code is embedded into the HTML page like JavaScript, and uses functions from within the VBScript base classes and from within the ActiveX controls which may be downloaded.
To summarize the advantages of ActiveX and VBScript:
Using distributed objects makes a lot of sense when you begin thinking of how the Internet works. The applications that are being written and downloaded by clients do not need a formal installation routine and can be used whenever the need arises. However, like the virus threat that began in the 1980s and is still very prevalent, there is a healthy concern about the security aspects of downloading programs on-the-fly.
Security of distributed objects is based on two concepts, trust and isolation. For example, if your friend wrote an application and gave it to you, you would probably feel fairly confident that the application would not contain any malicious code. The same feeling applies to applications that you may purchase from a local retailer or via mail order. There is a certain level of trust that you have put into the sources from which you've obtained the software.
This next section covers the various methods that are used to ensure some level of security when a user runs a distributed application.
The ActiveX method of maintaining security through the distributed objects that are used is by assigning a digital "fingerprint" to create a verified object when it is released. A verified object is one from which a registration number has been obtained through a third-party like VeriSign. That registration is embedded into the object to allow you to trace the author of the object.
For example, let's assume a programmer writes an object that can display various obscure graphic image types. In order for others to use this object within their distributed applications, the object must be placed into a location from which it can be accessed. The programmer chooses to place the object into an archive on a server which holds other distributed objects. In order for that object to be accepted, however, the programmer must register the object and provide detailed information like a street address, e-mail address, and phone number by which the programmer can be reached. This registration process provides some assurance that a malicious object, or an object with a serious bug, can be traced back to its author. This also provides a level of comfort to the user downloading the object that the author is responsible for the actions of their code. Now, this registration process will probably not stop the hardened criminal from bypassing these safeguards, but it will curb the flow of amateurs who may see this as an easy way to get noticed. See the section "Code Signing" for more information on the mechanisms involved with this type of security.
The mechanism for maintaining a trust relationship between distributed object developers and end users is by using a mutually trusted third-party. This is done through the use of authoritative digital signatures which are assigned to a registered developer. A certificate authority (CA) holds information which positively identifies the developer and holds the developer responsible for not releasing intentionally malicious programs. Once a developer has signed a legal document that promises to abide by the CA's rules, then the developer will receive a digital certificate which can be used to cryptographically "sign" all of the programs which are released from that developer.
The cryptographic signing will ensure that the code is from a particular developer and that the code has not been tampered with since it left the developer's hands. This allows end users to accept code which has been signed by particular CAs which the end user is familiar with and trusts. The digital signature also provides the end user with the knowledge that the developer who signed the code has taken steps to ensure their reputation.
For more information on obtaining a digital ID signature through a certificate authority, check VeriSign's Web site at http://digitalid.verisign.com/.
When an anonymous distributed object is called from an application you are running from within a Web page, you should have a certain level of paranoia regarding the functionality of the application. This is where the second concept of securing distributed objects comes in. By running an application in a contained environment, the objects will not be allowed to run rampant on your workstation and destroy your data. Instead, misbehaved applications may cause the browser to fail or possibly cause the application that was calling the object to self-destruct. Sealing off these unknown applications and distributed objects allows the system to protect itself from the virus-like activities which might be built into the distributed objects. The most common method of creating a contained environment, know as a virtual machine, is explained in the next section "Virtual Machines."
Obviously, the security of any system depends on the strength of the mechanisms involved. For instance, the Netscape Navigator version 2.01 contained a bug which could have been used to create a Java "virus" application. Netscape released version 2.02 to correct this fault, but the same type of problem can occur with any browser or operating system.
The only way to completely prevent malicious distributed objects from causing damage is by shutting off any distributed application usage. This will obviously remove all of the benefits of using distributed applications. Two methods of preventing damage caused by distributed objects is to enable all of the error-checking and monitoring switches on your current browser and by maintaining the most current browser release which will include fixes for known security holes.
A virtual machine is an environment in which applications may run with a restricted access to real system resources. For example, a Java virtual machine includes the ability to allocate memory resources dynamically, but restricts the ability to write to the system's hard drive or to communicate with another process on the system. These types of restrictions allow the end users a sense of well-being when they run an application which operates within a virtual machine. The user will not need to worry about a virus infection or a malicious application, because no damage can be done outside of the virtual machine.
An additional advantage that a virtual machine carries is the ability to create an environment within any operating system on any platform. A virtual machine is just that, a virtual operating environment that can work the same on every platform. This powerful advantage allows developers the ability to create applications which can literally be run within virtual machines on every platform which is supported. For example, an application written for a virtual machine environment may be run on a computer with DOS or Windows, a Macintosh computer, or even a mainframe. As long as the virtual machine environment is consistent from platform to platform, the application can make the same function calls and operate the same way.
The main disadvantage to using a virtual machine is that the code that is created to run within the virtual machine environment is a compiled "byte-code," which must be interpreted when the program is run. This causes the applications to perform more slowly than natively compiled applications. It is unlikely that the objects running in a virtual machine will be used for computationally complex applications in which the user would notice much of a difference between a native application and one running on a virtual machine.
Now that you've had a brief tour of distributed objects and their usage, you'll want to move forward and start to learn about how VBScript can make use of these distributed objects to produce a robust distributed application. You may want to check out these chapters next:
| Previous Chapter | Next Chapter |
| Search | Table of Contents | Book Home Page | Buy This Book |
| Que Home Page | Digital Bookshelf | Disclaimer |
To order books from QUE, call us at 800-716-0044 or 317-361-5400.
For comments or technical support for our books and software, select Talk to Us.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
